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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage 2 description of the Super-Charger that provides a mechanism to reduce the 
signalHng traffic associated with mobihty. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 21.905: "3G Vocabulary". 

[2] 3GPP TR 23.912: "Technical Report on Super-Charger". 

[3] 3GPP TS 23.007: "Restoration Procedures". 

[4] 3GPP TS 23 .008 : "Organisation of Subscriber Data" . 

[5] 3GPP TS 23.012: "Location Management Procedures". 

[6] 3GPP TS 23.016: "Subscriber Data Management: Stage 2". 

[7] 3GPP TS 23.040: "Technical Realisation of the Short Message Service (SMS); Point-To-Point 

(PP)". 

[8] 3GPP TS 23.060: "General Packet Radio Service; Stage 2". 

[9] 3GPP TS 29.002: "Mobile Application Part (MAP)". 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document the following terms and definitions apply. 

Procedure Calls to stage 2. 

Super-Charged Network: UMTS network in which the Super-Charger mechanism is being used to optimise 

mobility management signalling 

Network Entity: either an MSC/VLR, SGSN or UMSC 

Serving Network Entity: network entity to which the mobile station is attached 

Previous Network Entity: network entity to which the mobile station was attached prior to the serving network 

entity 
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3.2 Abbreviations 

Abbreviations used in the present document are listed in GSM 01.04. 

4 Information flows 

In a Super-Charged network subscription data is retained by the previous network entity when the subscriber roams to a 
new network entity. 

When a subscriber performs location updating in a Super-Charged network the HLR shall only cancel the subscription 
information at the previous network entity if it does not support the Super-Charger functionality. If the network entity to 
which the subscriber has roamed has retained subscription data from a previous visit then the HLR shall only send 
subscription data to the network entity if the retained subscription data is not consistent with the data stored by the 
HLR. If the HLR does not send subscription data to the serving network entity it shall treat the retained subscription 
data as valid. 

4.1 Location Updating in a Super-Charged Network 

4.1 .1 CS-domain Location Updating in a serving network entity tliat does 
not inave subscription data 

When a Super-Charged network entity receives a request to perform a location update for a subscriber for whom there is 
no record, the network entity shall initiate the location updating procedures as described in 3GPP TS 23.012. 

The Super-Charged HLR shall determine whether the previous network entity supports the Super-Charger functionality: 

if the previous network entity does not support the Super-Charger functionality then the HLR shall respond to 
the location updating request as described in 3GPP TS 23.012; 

if the previous network entity supports the Super-Charger functionality then the HLR shall respond to the 
location updating request as described in 3GPP TS 23.012 but shall not cancel the location information at the 
previous network entity. 
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Figure 1 : Information flow for an inter-node location update in a Super-Charged network for the case 
when the serving network entity does not have subscription data for the requesting mobile station 

Note 1 : If the previous network entity supports the Super-Charger features the HLR shall not send the cancel 
location message to the previous network entity. 

4.1 .2 CS-domain Location Updating in a network entity tinat inas retained 
subscription data 

When a Super-Charged network entity receives a request to perform a location update for a subscriber for whom 
subscription data has been retained, the network entity shall initiate the location updating procedures as described in 
3GPPTS 23.012. 

The Super-Charged HLR shall determine whether the previous network entity supports the Super-Charger functionality: 

if the previous network entity does not support the Super-Charger functionality then the HLR shall cancel the 
location information at the previous network entity as described in 3GPP TS 23.012. 

if the previous network entity supports the Super-Charger functionality then the HLR shall not cancel the 
location information at the previous network entity. 

The Super-Charged HLR shall determine whether the subscription data retained by the serving network entity is 
consistent with the subscription data stored in the HLR: 

if the subscription data is consistent then the HLR shall not send subscription data to the serving network entity 
as part of the location updating; 

if the subscription data is not consistent then the HLR shall respond to the location updating request as described 
in 3GPP TS 23.012. 
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Figure 2: Information flow for an inter-node location update in a Super-Charged network for the case 
when the serving network entity has retained subscription data for the requesting mobile station 

Note 1 : If the previous network entity supports the Super-Charger features the HLR shall not send the cancel 
location message to the previous network entity. 

Note 2: If the subscription data retained by serving network entity is consistent with the subscription data stored by 
the HLR, the HLR shall not send subscription data. 

4.1 .3 PS-domain Location Updating in a network entity tiiat does not iiave 
subscription data 

When a Super-Charged network entity receives a request to perform a routeing area update or attach for a subscriber for 
whom there is no record, the network entity shall initiate the location updating procedures as described in 3GPP TS 

23.012. 

The Super-Charged HLR shall determine whether the previous network entity supports the Super-Charger functionality: 

if the previous network entity does not support the Super-Charger functionality then the HLR shall respond to 
the location updating request as described in 3GPP TS 23.012; 

if the previous network entity supports the Super-Charger functionality then the HLR shall respond to the 
location updating request as described in 3GPP TS 23.012 but shall not cancel the location information at the 
previous network entity. 
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Figure 3: Information flow for an inter-node routeing area update or attach in a Super-Charged 
network for the case when the serving network entity does not have subscription data for the 

requesting mobile station 

Note 1 : This procedure is optionally performed as part of the Attach procedures, see 3GPP TS 23.060. 

Note 2: This procedure is used to update PDP contexts during a routeing area update when there is a one or more 
PDP Contexts established, see 3GPP TS 23.060. 

Note 3: If the previous network entity supports the Super-Charger features the HLR shall not send the cancel 
location message. 

4.1 .4 PS-domain Location Updating in a network entity tinat inas retained 
subscription data 

When a Super-Charged network entity receives a request to perform a routeing area update or attach for a subscriber for 
whom subscription data has been retained, the network entity shall initiate the location updating procedures as described 
in 3GPP TS 23.012. 

The Super-Charged HLR shall determine whether the previous network entity supports the Super-Charger functionality: 

if the previous network entity does not support the Super-Charger functionality then the HLR shall cancel the 
location information as described in 3GPP TS 23.012; 

if the previous network entity supports the Super-Charger functionality then the HLR shall not cancel the 
location information. 

The Super-Charged HLR shall determine whether the subscription data retained by the serving network entity is 
consistent with the subscription data stored in the HLR: 

if the subscription data is consistent then the HLR shall not send subscription data to the serving network entity 
as part of the location updating procedures; 
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Figure 4: Information flow for an inter-node routeing area update or attach in a Super-Charged 
network for the case when the serving network entity has retained subscription data for the 

requesting mobile station 

Note 1 : This procedure is optionally performed as part of the Attach procedures, see 3GPP TS 23.060. 

Note 2: This procedure is used to update PDP contexts during a routeing area update when there is a one or more 
PDP Contexts established, see 3GPP TS 23.060. 

Note 3: If the previous network entity supports the Super-Charger features the HLR shall not send the cancel 
location message. 

Note 4: If the subscription data retained by serving network entity is consistent with the subscription data stored by 
the HLR, the HLR shall not send subscription data. 
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Functional behaviour 



This clause describes the implementation of Super-Charger feature. This mechanism can reduce the signalling traffic 
associated with mobility, provided the HLR and serving network entity (i.e. MSC/VLR, SGSN, and UMSC) support the 
Super-Charger functionality. 



5.1 Subscriber Settings 



The Super-Charger feature requires a mechanism using which the HLR can determine whether the subscription data 
retained by the serving network entity is valid. In this specification this parameter shall be referred to as the age 
indicator. The format of the age indicator is implementation specific since it shall be defined and used by the HPLMN. 
The HLR shall store the age indicator and an indication as to whether the previous network entity supported the Super- 
Charger functionality on a per subscriber basis. 

The serving network entity shall store the age indicator provided by the HLR and an indication as to whether the HLR 
supports the Super-Charger functionality on a per subscriber basis. 



5.2 Data Consistency 



In a Super-Charged Network, subscription data may be retained by a number of network entities. Each Super-Charged 
network entity provided with subscription data will retain this information when the subscriber roams to a different 
network entity. 

5.2.1 Modification of subscription data 

If the subscription data is changed in the HLR the copy of the data in each of the network entities will become outdated. 
To ensure data consistency: 

the HLR shall update the age indicator to reflect the change in the subscription data; 

the subscription data in the serving network entity shall be updated as described in 3GPP TS 23.012. The 
subscription data provided to the serving network entity shall include the new age indicator. 

5.2.2 Location Updating 

The location updating procedures shall be initiated according to 3GPP TS 23.012. 

5.2.2.1 Detailed Procedure in the serving network entity 

If the serving network entity has retained subscription data, it shall provide the age indicator as part of the location 
updating procedure. 

If the serving entity has retained subscription data and does not receive subscription data as part of a successful location 
updating procedure, the serving entity shall treat the retained subscription data as valid and indicate successful 
completion of the location updating procedure towards the mobile station. 

If the serving entity has retained subscription data then subscription data received as part of a successful location 
updating procedure shall be treated as described in 3GPP TS 23.012. 

The procedure Check_User_Error_In_Serving_Network_Entity is defined for the case when the serving entity has 
retained subscription data but receives a negative response to the location update procedure. In this case, the serving 
entity shall not treat the retained subscription data as valid. If the negative response indicates "Unknown Subscriber" or 
"Roaming Not Allowed" the serving network entity shall delete the retained subscription data. 
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Procedure Check_User_Error_ln_Serving_Network_Entity 

I N 

Figure 5: Procedure in a Super-Charged serving networl< entity to determine wlietlier retained subscription data 
sliail be deleted following the receipt of a negative response to the location updating procedure. 
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Figure 5: Procedure CheckUserErrorlnServingNetworkEntity 
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5.2.2.2 Detailed Procedure in the HLR 

The procedure Super_Charged_Location_Updating_HLR determines when a Super-Charged HLR shall send 
subscription data to the requesting network entity. 

If the serving network entity indicates support for Super-Charger and includes the age indicator, the HLR shall use the 
age indicator to determine whether the subscription data retained by the serving network entity is valid i.e. the same as 
the subscription data stored in the HLR: 

If the subscription data retained by serving network entity is invalid, then the HLR shall send subscriber data to 
the requesting entity including an indication of support for the Super-Charger functionality and the age 
indicator. 

If the subscription data retained by the serving network entity is valid, then the HLR shall not send 
subscription data to the requesting entity. 

If the serving network entity indicates support for Super-Charger but includes a request for subscription data, the HLR 
shall send subscriber data to the requesting entity including an indication of support for the Super-Charger functionality 
and the age indicator. 

If the serving network entity does not indicate support for Super-Charger the HLR shall send subscriber data to the 
requesting entity. 
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Procedure Super_Charged_Location_Updating_HLR 

Figure 6: The procedure Super_Charged_Location_Updating_HLR determines when a 
Super-Charged HLR shall send subscription data to the requesting networl< entity. 



1(1) 




yes 



Serving NetwocK no 

^Entity Supports ^ 

Super-Charg 



yes 



yes 



Result:=Pass 





yes 




Result: = Fail 



Figure 6: Procedure Super_Charger_Location_Updating_HLR 
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5.2.3 Cancel Location 

The cancel location procedures are normally not used within and between Super-Charged networks as part of the 
location update procedure, as described 3GPP TS 23.012. However, Super-Charged networks shall support the cancel 
location procedure to provide interworking for location update procedures with GSM & UMTS networks that do not 
support the Super-Charger functionality. The cancel location procedure shall also be used within a Super-Charged 
network as a notification when there is a need to inform the previous network entity that the connections for the 
subscriber can be released, due to the fact that the MS has moved to another network entity. Subscription data may still 
be kept in the previous network entities that support Super-Charger. 

The mechanisms used to determine which network entities the cancel location message shall be sent to are outside the 
scope of this specification. However, it is recommended that the HLR store an indication if the serving network entity 
supports the Super-Charger functionality. It is also recommended that an HLR supporting the Super-Charger 
functionality have mechanisms to decide when a notification as described above needs to be sent against previous 
network entity or not. Without such mechanisms. Cancel Location shall always be sent. The mechanisms are triggered 
by the indication received from serving network entity during location update procedure saying that previous network 
entity must be notified. These mechanisms are triggered when there is a risk data inconsistency between nodes in the 
network, and are detailed in 3GPP TS 23.912. 

5.2.3.1 Detailed procedures in the serving network entity 

A Super-Charged serving network entity shall be capable of receiving a cancel location message as described in 3GPP 
TS 23.012. 

5.2.3.2 Detailed procedures in the HLR 

The procedure Super_Charged_Cancel_Location_HLR determines to whether a Super-Charged HLR shall send the 
cancel location message to the previous network entity during location updating as described in 3GPP TS 23.012. 

If the previous network entity does support the Super-Charger functionality, the HLR shall not send the cancel location 
message during location updating except in the conditions described in section 5.2.3.. This is indicated by the "Result:= 
Pass" exit in figure 7. 

5.2.4 Purge MS 

In a Super-Charged network, the subscriber record for an MS may be deleted by database management procedure to 
free up capacity in the network entity to accept new subscribers as described in subclause 5.5. 

The procedure Purge_MS_in_Serving_Network_Entity determines whether a Super-Charged Serving Network Entity 
shall send the purge MS message to the HLR when deleting inactive subscription data. 

If the HLR does not support the Super-Charger functionality, the deletion of inactive subscription data shall initiate the 
purge MS procedure as described in 3GPP TS 23.012. This is indicated by the "Result:= Fail" exit in Figure 8. 

For the CS-domain, the restoration procedures for Super-Charged network entities shall be modified to minimize the 
number of unnecessary mobile terminated call and short message attempts. 

For the PS-domain, any attempt to establish a network-requested PDP context to a network entity that has no record for 
the subscriber shall proceed as described in 3GPP TS 23.060. 

In addition, the Mobile Terminating Short Message Service is modified to minimize the number of unnecessary mobile 
terminated calls and short message attempts. 
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Procedure Purge_MS_ln_Serving_Network_Entity 
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Figure 8: The procedure Purge_MS_in_Serving_Network_Entity determines whether a Super-Charged i ^ 
Serving Networl< Entity shall send the purge MS message to the HLR when deleting inactive subscription da^a. 
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Figure 8: Procedure Purge_MS_ln_Serving_Network_Entity 
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5.2.4.1 CS-domain restoration procedures 

Upon receipt of a request for a roaming number, if there is no subscriber data record in the recipient network entity the 
network entity shall distinguish two cases: 

the subscriber data record was lost due to network entity restart; 

the subscriber data record was removed by the Super-Charger database management function described in 
subclause 5.5. 

If the subscriber data record was lost due to a network entity restart the restoration procedure as described in 3GPP TS 
29.002 shall be initiated. 

The procedure Check_Reason_In_Serving_Network_Entity determines whether the subscriber data was removed by the 
Super-Charger database management function and whether the network entity shall return the Purged MS diagnostic 
information to the HLR. 

The procedure Super_Charged_SRI_Error_HLR determines whether the HLR shall mark its data for the MS as purged 
and maps the Purged_MS diagnostic information to indicate that the IMSI is detached, in the send routeing information 
response. Consequently any request for routeing information for a mobile terminated call or a mobile terminated short 
message shall be treated as if the MS is not reachable. 

The means by which the network entity distinguishes the two cases is implementation dependent and therefore outside 
the scope of this specification. 
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Procedure Check_Reason_ln_Serving_Network_Entity 
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Figure 9: The procedure CheckReasonJnServingNetworkEntity determ ines whether the subscriber data was removed 
by the Super-Charger database management function and sets the Purged IVIS diagnostic information, if required. 




yes 




yes 

Set negative 
response: 
Purged MS 



Result: = 
Purged 



Result:= 
Not Purged 




Figure 9: Procedure CheckReasonJnServingNetworkEntity 
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Procedure Super_Charged_SRI_Error_HLR 
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Figure 10: The procedure Super_Charged_SRI_Error_HLR determines whether the HLR shall mark its data for the MS 
as purged and maps the Purged_MS diagnostic information to indicate that the I MSI is detached, in the send routeing^ 
information response. 
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Figure 10: Procedure Super_Charged_SRI_Error_HLR 
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5.2.4.2 



Mobile Terminating Short Message Service 



The procedure Check_Absent_SubscriberSM_In_HLR determines whether the HLR shall mark its data for the MS as 
purged based on the content of the absent subscriber SM diagnostic information (See 3GPP TS 23.040), if received 
from the SMS-GMSC, following a Mobile Terminating Short Message delivery attempt. 



Procedure Check_Absent_SubscriberSM_ln_HLR 

r N 

Figure 1 1 : The procedure Check_Absent_SubscriberSM_ln_HLR determines wiiether tine HLR shail 
marl< its data for the IVIS as purged and based on the outcome of a IVIT-SMS delivery attempt. 



1(1) 




yes 




yes 



Set IVIS 
Purged Flag 




Figure 11: Procedure CheckAbsentSubscriberSMJnHLR 
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5.3 Subscriber Deactivation 

When a subscriber is deactivated, the cancel location message is sent to the serving network entity and the subscription 
data shall be deleted in the HLR. 

Subsequently, when the subscriber attempts to register in a network entity that has data for the subscriber, the HLR will 
return an error of 'Unknown Subscriber' and the subscription data in the network entity shall be deleted as described in 
subclause 5.2.2.1. 



5.4 TIVISI IVIanagement 



In a Super-Charged network, if the cancel location or purge MS procedures are not performed the TMSI and P-TMSI 
values shall be de-allocated by another mechanism to avoid double allocation of temporary identifiers. 

If the send identification procedure as described in 3GPP TS 29.002 is used, the previous network entity may use this to 
explicitly de-allocate the temporary identifier assigned to that subscriber. 

In the event that the send identification procedure is not perform or not used as an explicit de-allocation trigger, it is 
recommended that an alternative mechanism is available to de-allocate temporary identifiers. The chosen mechanism is 
an implementation detail. De-allocation of TMSI and P-TMSI values may be achieved by a system of supervision 
timers or as part of the database management function, see subclause 5.5. However, other mechanisms maybe used to 
avoid double allocation. 



5.5 Database IVIanagement 



In a Super-Charged network subscription data shall not be deleted in the previous network entity. The subscription data 
shall be retained using spare capacity available in the network entity. This results in a continuous growth of the database 
size. If not managed properly, the network entity will eventually become full and unable to handle newly arrived MSs. 
A strategy to manage the capacity of Super-Charged network entities is required. 

The database management scheme shall be an implementation option and so outside the scope of this specification. 
Example mechanisms are: 

Utilisation of a larger database. 

Periodic audit scheme. 

Implementation of a strategy to make room for new users by removing old subscriber information from the 
associated database. 



5.5.1 Utilisation of a larger database 



The implementation of larger databases may be used to limit the need for other mechanisms to ensure that sufficient 
database capacity is available to service new subscribers. However, the need for an alternative mechanism such as 
Periodic Audits and Dynamic Subscription Data Deletion is not removed. 

Implementing larger databases such that subscription data is retained for an increased number of subscribers can 
increase the benefit from a Super-Charged network. However, the optimal database capacity will be network specific. 

The implementation of a larger database is not a requirement for this feature. 

5.5.2 Periodic Audit 

This scheme periodical removes inactive subscription data from the VLR and SGSN databases. The volume of 
subscription data deleted should be based on an estimation of the growth of the database size during the audit cycle. 

The criterion for removal of the subscriber is outside the scope of this specification. Circuit Switched and Packet 
Service activity of the subscriber should be checked before any deletion. 
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5.5.3 Dynamic Subscription Data Deletion 

This scheme allows the run-time removal of subscription if the associated database is full. In this case, the oldest 
subscription data is deleted to make room for the newly arrived subscriber. This mechanism may be used in conjunction 
with the other scheme detailed above or as the only method by which to create available capacity within a database. 

The criterion for removal of the subscriber is outside the scope of this specification. Circuit Switched and Packet 
Service activity of the subscriber should be checked before any deletion. 

5.6 Enlianced User Identity Confidentiality 

If an MS configured to support Enhanced User Identity Confidentiality updates location at a serving network entity 
which has retained subscriber data from a previous visit, the normal procedure of Enhanced User Identity 
Confidentiahty as defined in 3 GPP TS 23.018 shall apply. 

The serving network entity shall replace the TEMSI stored in the subscriber data by the TEMSI received from the 
UIDN as a result of the Send IMSI operation. 



5.7 Exception procedure 



A Super-Charged network entity shall inform the HLR about the support of the Super-Charger functionality whenever a 
subscriber roams on to that network entity. This information shall be included in the update location message sent to the 
HLR. The HLR shall use this information to determine the most appropriate action. 

If the HLR does not support the Super-Charger functionality the HLR shall ignore this information and proceed 
according to 3GPP TS 29.002. 

If the serving network entity does not support the Super-Charger functionality the serving network entity shall ignore 
information relating to the Super-Charger feature and proceed according to 3GPP TS 29.002. 
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Contents of the messages 



This clause contains detailed description of the messages shown in Section 5 of the specification. 



6.1 Update Location 



The contents of this message are specified in 3GPP TS 29.002. In the case when the originating entity supports the 
Super-Charger functionality, the following Super-Charger specific information is defined: 



Information element name 


Required 


Description 


Super-Charger Supported In 
Serving Network Entity 


C 


WInen included, this parameter indicates that the 
originating entity supports the Super-Charger 
functionality. In addition, this parameter shall indicate 
either that subscription data is required or the date and 
time of the last known subscriber data modification. 


Inform Previous Network 
Entity 


C 


When included, this parameter indicates that the previous 

network entity needs to be informed about the update 

location. 

The parameter shall be included only if Send 

Identification has not been sent to the previous network 

entity. 



6.2 Update Location ack 

The contents of this message are specified in 3GPP TS 29.002. 

6.3 Update GPRS Location 

The contents of this message are specified in 3GPP TS 29.002. In the case when the originating entity supports the 
Super-Charger functionality, the following Super-Charger specific information is defined: 



Information element name 


Required 


Description 


Super-Charger Supported In 
Serving Network Entity 


C 


When included, this parameter indicates that the 
originating entity supports the Super-Charger 
functionality. In addition, this parameter shall indicate 
either that subscription data is required or the date and 
time of the last known subscriber data modification. 


Inform Previous Network Entity 


C 


When included, this parameter indicates that the 

previous network entity needs to be informed about the 

update location. 

The parameter shall be included only if SGSN Context 

Request has not been sent to the previous network 

entity. 
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6.4 Update GPRS Location ack 

The contents of this message are specified in 3GPP TS 29.002. 



6.5 



Insert Subscriber Data 



The contents of this message are specified in 3GPP TS 29.002. In the case when the originating entity supports the 
Super-Charger functionahty, the following Super-Charger specific information is defined: 



Information element name 


Required 


Description 


Super-Charger Supported In 
HLR 


C 


When included, this parameter indicates that the 
originating entity supports the Super-Charger 
functionality. In addition, this parameter is used by the 
HLR to indicate the age of the subscription data stored 
in the HLR. 



6.6 



Insert Subscriber Data ack 



The contents of this message are specified in 3GPP TS 29.002. 
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